InfoMagic Internet Tools 1995 April/Internet Tools.iso/infoserv/gopher/Gopher_Conference_94/Papers/SafeGopher.Z/SafeGopher

Text File | 1994-04-20 | 11.1 KB | 330 lines

Guide to Safe Gophering

Paul Lindner



In any software product as large and complex as gopher there is the possibility of security holes. In this paper we'll show
you what they are and how to run a secure gopher server, gopher client, and gopher public access system.



April 18, 1994

1.0    Introduction

Gopher has had its small share of security problems. The
University of Minnesota, in conjunction with CERT and
other computer security agencies attempts to keep the
Gopher software as secure as it possibly can.

Now that the gopher software is installed on thousands of
sites it is imperative that all holes be documented and
fixed. We believe that release 1.13 and 2.013 are free of
security holes and that you should upgrade to these
releases as soon as possible.

We make no claims as the security or insecurity of other
software. This paper only applies to the Unix/VMS
Gopher Software released by the University of Minnesota.

2.0     The Origin of Holes

There are a few programming practices and design deci-
sions that have caused most of the holes in gopher soft-
ware. These practices pervade other software packages
too.

2.1    Use of software routines to insure security.

The most popular method of maintaining a secure environ-
ment is to use the chroot() system call to change the loca-
tion of the / directory to a subdirectory. This is the method
used by most FTP servers. Consider the following code
snippet:

 chroot("/usr/local/gopher-data");

This code causes the program to instantly think

/usr/local/gopher-data

is the slash directory. Thus if you try to access /etc/passwd
you will, in fact, be attempting to access

/usr/local/gopher-data/etc/passwd

There are a couple of problems with this scheme however.
The first is that you need root privileges to use this system
call. Also, sometimes you want to access files that aren't in
your gopher-data directory. For instance you might want
to make a symbolic link to your manual pages like this:

 ln -s /usr/man /usr/local/gopher-data/manual-pages

The solution to both of these problems was contributed by
John Sellins from the University of Waterloo.

Instead of relying on the chroot() system call, a suite of
software routines were written to insure that all requests
are legitimate. The routines strip out all occurrences of `..'
in gopher requests and append the server data directory to
certain requests. If these checks weren't in place a cracker
could do this:

 0/../../../../../../../../../../etc/passwd

This request would retrieve the password file of the system
running the gopher server if it wasn't for the dot stripping
routines.

Our example of a symbolic link works however, since
there aren't any `..' character strings in the request.

As we'll see later, bugs and oversights in this section of
code have caused security holes.

2.2    Use of Dangerous Routines in the Server
and Client

The server and client use two highly dangerous routines to
implement portions of the code. These calls are system()
and popen(). The server uses this code to decompress files
on the fly and run shell scripts to perform functions not
implemented in the server. The client uses these routines
to execute `helper' applications to send email, invoke tele-
communications download protocols and display many
data types.

The problem with both of these calls is that they use the
shell `sh' to evaluate the expression sent to them. The shell
has a very extensive feature set that makes it difficult to
ensure security through software routines. It's possible for
a malicious user to exploit these weaknesses to actually
run commands on the server. For instance the gopher
server has a special notation for running an external shell
script. Here's an example:

 exec:arg1 arg2:/bin/legisearch

In this case the server executes:

 popen("/bin/legisearch arg1 arg2");

which in turn executes:

 sh -c "/bin/legisearch arg1 arg2"

In earlier versions of the server a malicious user could
send the following command to a server running with the
`-c' (non-chroot) option:

 exec:arg1 ;cat /etc/passwd:/bin/legisearch

The server then would then execute:

 sh -c "/bin/legisearch arg1 ;cat /etc/passwd"

The semicolon (;) tells the shell to execute a second com-
mand and add the results to that of the first. In this case the
command prints out the contents of the Unix password
file.

This problem will only occur if you have shell scripts on
your server (the software will not execute non-existent
shell scripts.) If you're using the default chroot() mode a
cracker won't be able to get at files outside of the gopher
directory tree. However, they could still wreak major dam-
age to your gopher data.

This problem of hidden code execution plagued earlier
versions of the client as well. The Gopher client allows
connections to telnet sites by launching the telnet com-
mand with the name of a host. It does this by using the sys-
tem() system call like this:

 system("telnet pubinfo.ais.umn.edu");

However if an unscrupulous server administrator created a
bogus telnet item with a hostname like this:

 "pubinfo.ais.umn.edu;echo + >.rhosts"

This would cause the .rhosts file of the person using the
client to be compromised when they selected the item.
Gopher links like this are `telnet bombs' just waiting to be
opened, much like physical mail bombs.

Starting with release 2.0.12 we've started replacing these
routines with more general secure code that does not use
the shell. So far we've converted most of the client side
and some of the server calls. Eventually we will be rid of
this problem altogether.

3.0     Known Holes

Here is a list of the known holes in gopher and gopherd for
Unix system. It is probably not complete.

╖    All releases between 0.9 and 1.12 and 2.0 to 2.04 may
allow executing external commands with the exec:
facility.

╖    All releases between 2.0 and 2.012 and before 1.13
may allow `telnet bombs'.

╖    Releases before 2.0.12 had dedot routines that could be
tricked with the right combination of quotes and dots.

4.0     Known Bad Practices

These aren't holes really, but they are things that people do
that could prove very, very dangerous..

Some sites allow simultaneous ftp and gopher access to
the same set of files. Often a directory will be writable for
uploads for ftp users. If the execute bit is turned on for
uploads the cracker could upload shell scripts to the server,
which could then be activated by a gopher client.

5.0    Insuring Security of the Gopher
Server

Even with the potential for security holes it is still possible
to run a secure gopher server. The following steps are
insurance against future security holes.

The safest thing in any circumstances is to not run the
server at all. If you are very security conscious you may
not want to trust your data to software that doesn't come
with a warranty.

However this is short sited at best. There are a number of
techniques to make your gopher server secure.

╖    Avoid the chroot() (-c) option if you can. This is per-
haps the most dangerous portion of the gopher code.
It's been gone over with a fine tooth comb, but there's
no guarantee that we've closed every loophole.

╖    Always, always, always run the server as a non-root
user i.d. The server has a -u parameter to set the user-
name. Use it! Any damage that a user can cause can be
minimized by running as a non privileged user.

╖    Be careful with shell scripts. The gopher server can't
save you from shooting yourself in the foot by using a
poorly written, insecure shell script.

╖    Always log your transactions! Use the -l option of
gopherd to specify a log file like this.

 -l /usr/adm/gopherlog

This will give you an audit trail in case anything hap-
pens. It also gives you a way to find anomalies in
access. A log analyzer will be able to tell you if you're
receiving a disproportionate number of connections
from certain sites

╖    If your server contains sensitive information you may
want to use the ip/hostname security option of the
server. This is done by using `access:' lines in your
gopherd.conf configuration file.

The following lines will allow only hosts from the Uni-
versity of Minnesota to access your server. Note that
this style of security has some obscure holes. If your
DNS server is compromised, then so is your gopher
server if it uses this form of authentication.

 access: default !read,!browse,!search,!ftp

 access: .umn.edu read,browse,search,ftp

╖    Consider executing your scripts with `taintperl'. This
version of perl makes sure that you never use user
input to execute a command on your system.

6.0     Insuring the Security of Your Client

The client is less problematic that the server, but it still has
it's own problems.

╖    Upgrade to 2.013 or higher. Earlier versions could
potentially execute a `telnet bomb'. If you read the
warning screen you'll probably notice it, but you could
easily miss it.

╖    Certain file types are inherently insecure. You should
trust the source of postscript and Microsoft Word docu-
ments before viewing them. Both systems can execute
system macros that could alter data and files on your
system. This is not a gopher problem, but a general
information retrieval problem. Other file formats can
potentially cause the same problems.

7.0     Insuring the Security of Your Public
Access Client

A public access client allows people to connect to the
internet, (often without a password) and use a gopher cli-
ent. This allows dial up users and those without the
resources to run a gopher client on their own system
access to the gopher network. A public access client can
be an enormous security risk if not installed properly. The
following steps should give you a secure public access cli-
ent, but again, we make no guarantees.

The first step is to create the home directory of the for the
guest account. This directory should not be writable nor
owned by the guest account.

In this directory you will want to place a shell script that
will start the gopher client automatically. Here is an exam-
ple:

#!/bin/sh

GHOME=/home/hafnhaf/gopher

USER=`whoami` export $USER

eval `tset - -s -m "network:?vt100" -m
"unknown:?vt100" -m "dumb:?vt100" -m
":?vt100"`

echo "I think you're on a $TERM terminal"

sleep 3

PATH=$GHOME/bin

export PATH

exec /home/hafnhaf/gopher/gopher -s $GHOST 70

Note that we set the path to a bin directory inside of the
guest account directory. We want to insure that only pro-
grams inside of this directory are run. The reason we do
this is that many programs allow you to get to a shell, like
telnet, tn3270, less, more and many others. You should put
secure versions of these programs in the bin directory
inside the guest directory.

Also note that we use the -s option for gopher. This
invokes the `secure' option of the client. In this mode the
client won't let you save or print.

Finally you can create the guest account. Make sure that
the shell is specified as the script. Don't put /bin/csh or /
bin/sh for the shell. Here's an example entry for a guest
account:

 gopher::10000:10:Public Access Account:/home/
gopher:/home/gopher/Startup

Don't forget to honor the warnings for the regular client as
well. On public access systems people will actually try to
run telnet bombs.